1. Field of the Invention
The invention relates to a portable token which commands can be protected by access conditions. It also relates to a system comprising a portable token and a middleware for accessing the portable token, and to a method for selecting the access conditions applicable to a portable token.
2. Description of the Related Art
In the context of the invention, portable tokens are electronic devices which can be easily carried by an individual, and which can receive orders from other entities in the form of commands. Common examples of portable tokens include smart cards, USB keys, MMC or SD cards, etc. smart cards have various applications (e.g. bank cards for financial applications, SIM cards for mobile telephony, contact-less cards such as Navigo for public transportation, healthcare cards such as Sesame Vitale, etc.). Smart cards can implement a contact interface, a contact-less interface, or both contact and contact-less interfaces. They can also offer different types of interfaces in the same category (e.g. ISO 7816 and USB are both contact interfaces which can be simultaneously supported by a given smart card).
Certain portable tokens offer security features allowing them to protect access to their commands based on access conditions. An entity willing to read certain private data from such portable token may be denied access if it does not prove its knowledge of a PIN code or of a cryptographic key, while the same entity would be authorized to read public data or to call all sorts of innocuous commands. On ISO 7816 compliant portable tokens, access conditions defining the level of protection of commands giving access to sensitive data or/and services, including cryptographic services such as digital signature, is mainly performed via ISO/IEC 7816-4 security architecture (see for example clause 5.4). Security attributes are attached for example to data (data comprise files and logical data structures), or to cryptographic objects (including objects nested in files or in logical data structures), and typically comprise access mode bytes and related security conditions. Such security attributes are generally nested in a File Control Parameter template (see for example clause 5.3.3). Such security attributes are static, in the sense that they are the same whatever the environment from which the portable token receives commands. ISO/IEC 7816-4 does not provide any specific means to distinguish between two or more different environments and to define dynamic access conditions wherein a different set of security attributes is used depending on the current environment. The term environment encompasses not only the interface through which the communication takes place, but also the entity initiating the communication with the portable token by sending commands. For example two different entities could send commands through the same interface (e.g. a IEEE 1394 firewire interface), or the same entity could send commands alternatively through several interfaces (e.g. a USB interface, an ISO 7816 interface, and a Mifare contact-less interface). In both cases, the environments are different, and ISO 7816-4 does not address the possibility to tailor the access conditions to each environment.
ISO 24727 specifies certain environments for smart cards and possibly other types of portable tokens. An initial step of a transaction in a 24727-environment is the bootstrap mechanism described in ISO/IEC 24727-2—Identification cards—Integrated circuit card programming interfaces—Part 2: Generic Card Interface. The ATR (Answer To Reset, standardized in ISO 7816), is the answer of a smart card to a reset signal, and consists in a series of bytes informing the terminal to which the smart card is connected of the characteristics of the smart card. After ATR/ATS, the Generic Card Access Layer (GCAL) part of a 24727 middleware stack may read a Card Capability Container called CCD from the smart card. The CCD comprises a set of data objects that deliver information reflecting the smart card capabilities to the middleware. Several alternatives are available through the standard (ref. ISO/IEC 24727-2 clause 6.4.2) for determining the value of the CCD. For example, the CCD may be obtained from the initial data string as per ISO/IEC 7816-4, by GET DATA based on the CCD, by reading the relevant part of EF.ATR, or by selecting a dedicated alpha card-application hosting the CCD and by then applying a GET DATA to retrieve the CCD. The CCD should preferably be available on smart cards in order to fit properly in 24727 environments. The CCD typically contains a piece of bytecode called “Procedural Elements” and nested in a data object ‘A1’ called “Procedure Elements Description Template”. These Procedural Elements are used mainly to translate the generic APDUs from the Service Access Layer into APDUs understandable by the smart card. This translation takes place in the Generic Card Access Layer (GCAL). Procedural Elements are however not mandatory in ISO 24727, and some smart cards may implement the generic set of APDUs employed by the Service Access Layer (SAL ref. ISO/IEC 24727-3) and consequently do not require Procedural Elements since no translation is in principle necessary.
One problem with state of the art portable tokens is that they lack flexibility in their management of access conditions.